Telecommunication system architecture for extended open service access to multiple heterogeneous networks

ABSTRACT

A telecommunication system providing extended open service access to multiple heterogeneous networks has one unique common framework for the networks and a common service capability feature (SCF) for the networks to provide a common network interface.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a 371 of PCT/NO02/00260, filed Jul. 12, 2002, whichclaims priority of provisional application 60/304,780, filed Jul. 31,2001.

FIELD OF THE INVENTION

The present invention concerns a method and a system of providingapplication service access on multiple heterogeneous networks. Althoughoriginating from mobile communications, the present invention can beapplied to the whole telecommunication field. Furthermore, withconvergence between telecommunication and computing, this invention canalso be applied in data communication on packet-based networks such asIP (Internet Protocol) based networks.

BACKGROUND

In order to promote the development of third party applications the 3GPP(Third Generation Partnership Project), which is the stand-ardisationbody for third generation mobile system (UMTS), introduced the OpenService Access (OSA) for third generation Mobile System (UMTS). OSAstandards are defined in 3GPP, Virtual Home Environment; Open ServiceArchitecture (Release 4). Valbonne, 2001. (3GPP TS 23.127, V4.1.0,2001-04).

The OSA allows the applications to access the network servicecapabilities such as Call Control (CC), User Status (US), Messaging (M),Location Information (LI), etc. through open interfaces. Sucharchitecture will certainly play a key role in the realisation of one ormore “killer” applications, which is necessary for the success of UMTS.It is worth to stress that nobody knows yet what is going to be such a“killer” application. Indeed, for GSM nobody could predict that SMS(Short Message Service) has become the “killer” application.

OSA is only intended for mobile networks. However, with convergencebetween telecom and computing, between fixed and mobile, it is crucialthat an application is able to operate properly independently of theunderlying network. Consequently, it is necessary to extend the coverageof OSA to comprise also other networks than mobile ones such asPSTN/ISDN and also IP-based networks. It is worth noting that IP-basednetworks may be both wireline and wireless such as for example WirelessLAN (802.11). HiperLAN, or Bluetooth. The situation is depicted in.

Unfortunately, OSA was only intended for mobile networks and it is notspecified how to implement OSA for heterogeneous networks. Furthermore,OSA, as specified by the 3GPP, is not sufficient to be applied toheterogeneous networks. The present invention proposes differentembodiments to implement OSA on the top of several different networks.Also, additional functionality to OSA is required and proposed by thisinvention.

According to the knowledge of the inventors, no solution to the problemde-scri-bed above is known at present time. Even for the ParlayArchitecture, which OSA is based on, there is no activity ofimplement-ing Parlay on heterogeneous networks. Although in someoverview of the Parlay architecture it is shown a Parlay API coveringMobile networks, ISDN and IP-based network, there is no specificationfor the implementation.

SUMMARY OF THE INVENTION

In a first aspect the invention provides a telecommunication systemproviding application service access on multiple heterogeneous networks,comprising an open service access (OSA) extension with at least oneframework providing interfaces between the applications and the multipleheterogeneous networks.

A terminal ID administrator may be incorporated providing information tothe applications in selecting the required network based on terminal ID.

In a first embodiment the system comprises one unique common frameworkfor said networks and one service capability feature (SCF) for eachnetwork providing a network specific interface. The service capabilityfeatures may include a general service property indicating whichunderlying network a SCF is interacting with. The general serviceproperty is expressed as a string containing a <operator, network> pair.

Also in this embodiment a terminal ID administrator selects the requirednetwork service capability feature for an application based on terminalID. The terminal ID administrator may include a database/directorycontaining mapping information between applications and the terminalIDs. The terminal ID administrator may also comprise adatabase/directory containing mapping information between applicationsand the service capability feature instances, between the servicecapability feature instances and the networks, and between the networksand terminal IDs. The terminal ID administrator is updatable in realtime. An interface between the requesting application and the terminalID administrator is provided by a terminal administrator (TA SCF)containing interface classes for application queries. The terminaladministrator (TA SCF) includes program means for allowing anapplication to get a reference for the correct service capabilityfeature instance for a given terminal, to query the service capabilityinstance references for several terminal IDs simultaneously, to get anetwork ID of a given terminal, to get the references of all its servicecapability features instances, and to get the references of all itsservice capability features instances on a specific network.

In another embodiment the system may instead comprise one unique commonframework for the networks and a common service capability feature (SCF)for the networks providing a common network interface. A general serviceproperty may be included in the service capability features indicatingwhich underlying network a SCF is interacting with. This general serviceproperty is expressed as a set of strings, where each string contains a<operator, network> pair. The interface may include service capabilityinterface classes providing one to many mapping between applications andthe interfaces of the underlying networks.

Further, the common service capability feature may include a mappingmeans for mapping interface classes to the network interfaces and adispatcher means dispatching a request from an application to a correctnetwork interface class. A registration interface between the mappingmeans and the dispatcher means may enable registration of the networkswith the dispatcher. The dispatcher means includes selecting meansselecting the correct service capability feature (SCF) for a requestarriving from an application. A terminal ID administrator selects therequired network service capability feature (SCF) for an applicationbased on terminal ID. Mapping information between applications and theterminal IDs may be included in a terminal ID administratordatabase/directory. The database/directory includes mapping informationbetween applications and the service capability feature instances,between the service capability feature instances and the networks, andbetween the networks and terminal IDs. Also in this embodiment theterminal ID administrator is updatable in real time. The terminal IDadministrator (TA SCF) provides an interface for the SCF dispatchermeans, and the terminal ID administrator comprises program means whichwhen run provides getting a reference for the correct service capabilityinstance for a given terminal in order to dispatch the request to thatSCF instance, including getting the terminal ID that the application ishandled, getting the application ID of the requesting application, andthe references of the service capability feature instance returned bythe SCF instance.

In an even further embodiment the system may comprise a framework foreach network, each framework having a service capability feature (SCF)for said network providing a network specific interface. Each frameworkmay then include a mechanism enabling selection of a service capabilityfeature in another framework and receipt of a reference to said servicecapability feature. The selectable service capability features for theframeworks may be predefined. Each framework may also comprise aterminal ID informator providing a service capability function to theapplications regarding network selection based on terminal ID. Theterminal ID informator returns a string containing a <Terminal ID,belong (True/False)> pair to the requesting application. All theframeworks may include program means executing when requested, a mutualauthentication procedure. This may be the case each when otherframeworks requesting information about the service capability featuresoffered by said framework. For enabling this, the framework may comprisean extended interface. The extended interface may also include programmeans executing a request procedure returning an identity of therequesting framework together with a list of the predefined servicecapability features offered to said framework and a get procedureenabling a framework to request another network to return references ofthe service capability feature instances in accordance with the serviceproperties specified by the requesting application. The terminal IDadministrator selects the required network service capability featurefor an application based on terminal ID. Selecting is enabled by amapping function based on a database/directory interacting with theterminal ID administrator. The database/directory may also containmapping information between applications and the service capabilityfeature instances, between the service capability feature instances andthe networks, and between the networks and terminal IDs. An informationinterface provides the terminal ID administrator with informationconcerning terminal ID ranges supported by each framework may also beincluded in the terminal ID administrator. The terminal ID administratoris updatable in real time.

The heterogeneous networks includes but is not limited totelecommunication networks wireless or wireline, e.g. mobile, UMTS, GSM,PSTN/ISDN or computer networks like a packet based network, e.g. IP(wireline), Wireless LAN, Bluetooth or Hiper LAN (wireless).

In a further aspect the present invention provides a method of providingapplication service access on multiple heterogeneous networks,comprising implementing an open service access (OSA) extension with atleast one framework in an application programming interface (API) forthe heterogeneous networks providing interfaces between the applicationsand the multiple heterogeneous networks.

In an even further aspect the present invention provides a program of anapplication programming interface (API) for providing open serviceaccess for applications to multiple heterogeneous networks, the programcomprising a set of instructions for carrying out the method andimplementing the system above.

In another aspect the present invention provides a computer readablemedium having stored thereon an application programming interface (API)for providing open service access for applications to multipleheterogeneous networks, the computer readable medium comprising a set ofinstructions for carrying out the method and implementing the systemabove.

This invention will benefit different actors in telecommunications andinteracting areas, like e.g. network operators, service/applicationproviders and users in different ways. The network operators may be ableprovide more flexible services to the applications. They obtaintherefore larger number of applications and consequently higher trafficand also larger number of users. The service/application providers candevelop applications more easily and also more interesting applications.They do not have to be concerned with different networks. Theapplications are more generic since they can run on heterogeneousnetworks. Quite a lot of re-use and saving can be achieved since thesame application can be deployed at different networks. The user willenjoy a broader range of applications, which are enabled by the OSA APIon heterogeneous networks. Although this invention addresses the OSA itcould be applied for the PARLAY architecture since OSA relies quite alot on PARLAY.

As mentioned above the present invention solves a problem forservice/application providers since it is simpler to developapplications for heterogeneous networks. At the same time it provides anopportunity to network operators who have heterogeneous networks (e.g.fixed and mobile, telecom and IP-based). The invention is defined in theappended claims.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the invention will now be described with reference to thefollowing drawings, in which:

FIG. 1 depicts on the left a present architecture where applicationsaccess a mobile network via the OSA, and on the right an extended OSAfor heterogeneous networks according to an embodiment of the presentinvention,

FIG. 2 shows an extended OSA for heterogeneous networks according to afirst embodiment of the invention, using a common framework but whereeach network has its own SCFs,

FIG. 3 shows relationships maintained by the TA in the first embodimentof the invention,

FIG. 4 shows some of the properties of the Terminal ID Administrator inthe first embodiment of the invention,

FIG. 5 illustrates usage of Terminal Administrator SCF in the firstembodiment of the invention,

FIG. 6 is a view of an implementation of the present invention using acommon framework and a common SCF incorporating all underlying networks,

FIG. 7 shows usage of an SCF according to a further embodiment of theinvention,

FIG. 8 shows an example implementation of a second embodiment of theinvention,

FIG. 9 is a view of a dispatcher function in OSA according to a secondembodiment of the invention,

FIG. 10 illustrated the relationships maintained by the Terminal IDAdministrator according to a second embodiment of the invention,

FIG. 11 shows a third embodiment of the invention using one frameworkfor each underlying network,

FIG. 12 illustrates communication and collaboration between frameworksaccording to a fourth embodiment of the invention,

FIG. 13 illustrates usage of US SCF in both the GSM network and theIP-Based network according to the embodiment shown in FIG. 12, and

FIG. 14 shows communication between frameworks via OSA frameworkcommunication interfaces according to a fourth embodiment of theinvention.

DETAILED DESCRIPTION OF INVENTION

This invention consists of two main items:

-   -   The proposal of applying OSA on heterogeneous networks.    -   Embodiments for implementing OSA on heterogeneous networks. For        each embodiment, the required additional functions and their        incorporation onto OSA are described.

This invention provides extended coverage of OSA (Open Service Access),which is originally intended to third generation mobile networks, toheterogeneous networks, i.e. comprising also PSTN, ISDN and IP-basednetwork (Internet, Intranet). In the following, four embodiments toimplement OSA on heterogeneous networks will be described. The problemsrelated to each embodiment will be examined and required additionalfunctions and features presented.

Embodiment 1 A Common OSA Framework for All Networks and One ServiceCapability Feature for Each Network

In this embodiment, a single OSA framework is incorporating allnetworks, but each network has their own Service Capability Features(SCFs). The GSM/UMTS network will have its SCFs such as Call Control(CC) SCF, User Interaction (UI) SCF, User Status (US) SCF etc. The sameapplies to the PSTN/ISDN network and the IP-Based network as shown inFIG. 2.

Hence, each SCF is mapped into the interfaces specific for each network.How the mapping is done depends on the network. For example, the CC SCFresponsible for the GSM network is mapped onto the interfaces issuingCall Control in the GSM network. The same applies to the CC SCF in thePSTN/ISDN network and the IP-Based network. This leaves us with astandardised CC API to Call Control network service capabilities foreach of the networks in our heterogeneous network environment, allowingthird party applications to use Call Control capabilities in allnetworks. The same applies to other SCFs.

Required Additional Functionality

A. SCF Naming Scheme

An SCF for each underlying network needs to be identified and registeredwith the OSA Framework. Hence, the values of the Service Properties ofthe SCF needs to indicate which network each SCF belongs to. It is alsonecessary to recognise the owner of the network, i.e. the networkoperator. For this purpose a General Service Property called “UnderlyingNetwork” is introduced, which indicates which underlying network a SCFis interacting with. The property value is a string containing a pair<Operator, network>. For example for a User Status SCF the value couldbe: <Telenor, GSM> or <Netcom, GSM> or <Telenor, IP-based (SIP)>.

B. Selection of SCF Instance Based on Terminal ID

A major problem for the applications is how to select the correct SCFinstance based only on the terminal identificators, the terminal IDs.The terminal IDs could be a regular phone number, a name or an IPaddress. For example, the application needs to subscribe to the right CCSCF if it wants to establish call for certain terminals. Some TerminalIDs are not in the scope of the GSM network e.g. SIP addresses, and callrequests for these terminals should therefore not be addressed to theGSM network, but to the IP-based network.

Another issue is when the application wants to establish a call forexample a “click to call” application, it has to select which underlyingnetwork to establish the call, i.e. which CC SCF instance to use.

Further, problems occur when an application uses e.g. the User StatusSCF. The User Status (US) SCF allows applications to obtain the status(Reachable, Unreachable and Busy) of the user's terminals. The US SCFfor the GSM network is only capable of delivering user status forterminals in the scope of GSM network (GSM phones registered in theHLR), the US SCF for the IP-based network is only capable of deliveringuser status for the users registered in the SIP server, etc. Anapplication wanting to check the user status of a user has to select theright SCF instance, i.e. the right underlying network, according to theuser's Terminal ID. For example, if the Terminal ID is a GSM number, theapplication has to select the US SCF instance for the GSM network. Theapplication can then obtain the requested User Status by contacting theselected US SCF instance.

From the examples above, we observe that the applications have problemsto select the correct SCF instance when performing action on SCFs. Theyneed to have information on terminal naming/numbering, i.e. whichterminals belong to which networks. Furthermore, there should be a linkbetween the terminal IDs and the correct SCF instance. Such informationis not static but is subject to frequent changes and needs to be updatedfrequently since people do change terminals, operators and subscriptionsfrequently. There is a need for an additional function, say Terminal IDAdministrator, which assists the application in the selection of SCFbased on terminal IDs.

The Terminal ID Administrator (TA) incorporates a database/directoryservice containing the mapping between applications and SCF instances,the mapping between SCF instances and networks and finally the mappingbetween networks and terminal IDs, as shown in FIG. 3. The numbers inthe figure indicate the cardinality. 1 mean one and exactly one while +1means one or more. One application can have one or more SCF instance.One SCF instance has one and only one application. One SCF has one andonly one network while one network may have one or more SCF. One networkhas one or more terminals, but one terminal belongs to one and only onenetwork. The TA allows network operators to register changes when theyoccur, and allows applications to query information about all themappings mentioned above, e.g. the SCF instance for a set of TerminalIDs as illustrated in FIG. 4.

The TA provides useful functionality for any applications that uses OSA.The TA should therefore be easily accessible for applications. For thispurpose an OSA Service Capability Feature (SCF), say TerminalAdministrator SCF (TA SCF), is implemented which abstracts encapsulatesthe functionality of the TA as a standard API. The TA SCF containsinterface classes for application queries. The TA SCF interface forapplication queries contains the following methods which can be used bythe applications:

getSCFinstance(<terminalID>, <applicationID><SCFreference>),

<terminalID> is the terminal ID e.g. phone number that the applicationis handled

<applicationID> is the ID of the requesting application

<SCFreference> is the reference of the SCF instance returned by the TASCF

This method allows an application to get the reference of the correctSCF instance for a given terminal, e.g. e phone number.

getListofSCFinstances(<listofTerminalID>, <applicationID>, <listofSCFreferences>)

<listofTerminalID> is the list of terminal IDs to find SCF instance for

<applicationID> is the ID of the requesting application

<listof SCFreferences> is the list of references and correspondingTerminal IDs returned by the TA SCF

This method allows an application to query the SCF instance referencesfor several terminal IDs simultaneously.

getNetworkID(<terminalID>, <applicationID><NetworkID>),

<terminalID> is the terminal ID that the application is handled

<applicationID> is the ID of the requesting application

<NetworkID> is the ID of the network, which the terminal belongs to,returned by the TA SCF.

This method allows an application to get the network ID of a giventerminal.

getAllSCFinstance, (<applicationID><ListofSCFreference>),

<applicationID> is the ID of the requesting application

<SCFreference> is the list of the SCF instance references for anapplication returned by the TA SCF

This method allows an application to get the references of all its SCFinstances.

getAllSCFinstance, (<applicationID>, <networkID>,<ListofSCFreferencse>),

<applicationID> is the ID of the requesting application

<networkID> is the ID of the network, e.g. <Telenor, GSM>, <OperatorX,ISDN>, <OperatorY, IP-based>, etc.

<SCFreference> is the list of the SCF instance references for anapplication returned by the TA SCF

This method allows an application to get the references of all its SCFinstances on a specific network.

Example

Let us suppose that an application wants to obtain the user status for aterminal ID, e.g. phone number 12345678. The application sends a queryto the TA SCF (getSCFinstance), including the terminal ID>=12345678 andthe name of the SCF, <SCFtype>=“User Status”. In response, theapplication receives the object reference to the User Status SCF thatthe requested terminal ID belongs to. Now, the application can use thecorrect US SCF without being concerned with underlying networks. Hence,when using the TA SCF, this embodiment is confirmed with the goals ofOSA.

Embodiment 1 as explained above is summarized in FIG. 5.

Embodiment 2 A Common Framework and a Common SCF (Service CapabilityFeature) for All Networks

In this embodiment of the invention a single OSA framework isincorporating all networks and an SCF is representing all underlyingnetworks. For example the Call Control SCF will incorporate call controlcapabilities for the GSM/UMTS network, the PSTN/ISDN network and theIP-based network. The same applies to the other SCFs as shown in FIG. 6.

Hence, each SCF communicates with all networks. For example, the CC SCFis mapped into the interfaces issuing Call Control in the GSM network,the PSTN/ISDN network and the IP-Based network. The applications areable to perform call control on all networks using only a single CC SCF.The same applies for other SCFs.

Additional Functionality

A. SCF Naming Scheme

An SCF is now representing several underlying networks and it isnecessary to specify every one of them. It is also necessary torecognise the owner of each network, i.e. the network operator of eachnetwork.

In this embodiment of the invention it is introduced a General ServiceProperty called “Underlying Network”, which indicates which underlyingnetworks a SCF is interacting with. The property value is a set ofstrings where each string contains a pair: <Operator, network>. Forexample for a User Status SCF the value could be: {<Telenor, GSM>,<Netcom, GSM>, <Telenor, IP-based (SIP)>}. This is illustrated in theexample in FIG. 7. In FIG. 7 the application selects (trades) the UserStatus SCF in the GSM network and the IP based network, using thedesired Service Properties in the OSA Framework. This is indicated by 1in FIG. 7. The OSA Framework then agrees to the service trading, makes anew instance of a User Status SCF, which can interact both with theGSM/UMTS network and the IP-based network, and then returns a referenceto the User Status instance, to the application, as shown by 1.1 ‘New’in FIG. 7.

B. Dispatching Function

Each SCF is in this embodiment now responsible for all underlyingnetworks, thus the Interface Classes of a SCF need to be mapped to allthe interfaces for every network (One to many mapping). For example, theCall Control Interface Classes have to implement the mapping between theOSA Call Control API to the SS7 INAP for the PSTN/ISDN network, themapping between the OSA Call Control API and the SIP protocol for theIP-Based network and the mapping between OSA Call Control API and toCAMEL for the GSM/UMTS network. This is shown in FIG. 8.

Since the network equipment in each underlying network can be developedby different vendors (e.g. IN systems for GSM are developed by Ericsson,Alcatel; SIP servers developed by HotSip, Dynamicsoft, Ubiquity, etc.)some problems will occur. Each vendor is only able to implement themapping of the OSA interface classes to the interfaces to their networkequipment. In addition, the solution is not flexible since it isrequired that one vendor is developing the mappings from OSA InterfaceClasses to all the network specific interfaces in all heterogeneousnetworks.

In this embodiment of the present invention some necessary modificationsto OSA are made. An SCF is split into two separate components:

-   -   One component implementing the mappings from OSA Interface        classes to the interfaces of the underlying networks.    -   Another component responsible for dispatching a request from an        application to the correct SCF connected to the correct        underlying network.

By splitting the SCF into two components, network equipment vendors needonly develop the mapping of the OSA Interface Classes to the interfaceson their network equipment (One to one mapping) while applications needto deal with only one SCF instance even though the SCF interacts withmany heterogeneous networks. The component implementing the interfacemappings is practically identical to the SCFs specified in OSA.

The component responsible for dispatching request from applications, the“SCF dispatcher”, is an additional function to OSA. The interface to theapplications must of course be the same as specified for each SCF in theOSA specification.

In addition, there is a “Registration interface” between the two SCFcomponents, enabling the SCFs for each network to register with the “SCFdispatcher”. The network specific SCF provides the “SCF dispatcher” areference to itself and the Service Properties that it supports. Hence,the “SCF dispatcher” holds the knowledge of the capabilities for thenetwork specific SCF and is then able to register itself with the OSAframework, supplying the Service Properties that it supports, i.e. thesum of all the Service Properties provided by each network specific SCFinstance.

For each application, an instance of the SCF Dispatcher will be created.Depending upon which underlying networks the application is allowed touse service capabilities on, respective instances of SCF for eachnetwork will be created. The SCF Dispatcher instance stores thereferences of all these SCF instances. The “SCF dispatcher” alsoincorporates functionality to select the right SCF instance when arequest arrives from an application. To illustrate the necessity of sucha function, let us suppose that an application requests the status of auser to the US SCF. The Application has a Service Level Agreementindication that allows it to use the US SCF for the GSM network, thePSTN/ISDN network and the IP-Based network (SIP). The US SCF (“US SCFdispatcher”) is able to interact with all three underlying networks.Hence, it must be able to determine which underlying network the requestrelates to, in order to dispatch the request to the correct US SCFinstance. This is actually the same requirement as described in theprevious embodiment 1, namely selecting the correct SCF instance basedon the Terminal ID.

Therefore, the “SCF dispatcher” should use the Terminal ID Administrator(TA) to inquire the SCF instance from the Terminal ID. The “SCFdispatcher” is then able to dispatch the request from the application tothe correct SCF instance, using the result from the query to theTerminal-ID Administrator. Note, that all responses and reports from thenetwork SCFs go through the “SCF dispatcher” before being sent to therespective application. This is illustrated in FIG. 9.

C. Selection of SCF Instance Based on the Terminal ID

There is a need for a Terminal ID administrator as also shown in FIG. 9.The Terminal ID Administrator (TA) incorporates a database/directoryservice containing the mapping between applications and SCF instances,the mapping between SCF instances and networks and finally the mappingbetween networks and terminal IDs. The relationships maintained by theTerminal ID Administrator are shown in FIG. 10. The numbers in thefigure indicate the cardinality. 1 means one and exactly one, while +1means one or more.

The Terminal ID Administrator enables network operators to registerchanges when they occur. The Terminal ID Administrator also offers aninterface to the SCF dispatchers which contains the following method:

getSCFinstance(<terminalID>, <applicationID><SCFreference>), where

<terminalID> is the terminal ID that the application is handled

<applicationID> is the ID of the requesting application and

<SCFreference> is the reference of the SCF instance returned by the SCFinstance

This method allows the SCF dispatchers to get the reference of thecorrect SCF instance for a given terminal in order to dispatch therequest to that SCF instance.

The Terminal ID administrator in this second embodiment is not visibleand available to the applications in the same way as in the firstembodiment, but exists only inside the framework, e.g. for the SCFdispatcher.

Example

Let us suppose that an application wants to obtain the user status for aterminal ID, e.g. phone number 12345678. The application sends a queryto the CC SCF Dispatcher, including the <terminal ID>=12345678 and thename of the SCF, <SCFtype>=“User Status”. The CC SCF Dispatcher sends arequest (getSCF instance) to the Terminal ID Administrator via theTerminal ID to SCF instance mapping. In response, the CC SCF Dispatcherreceives the object reference to the User Status SCF that the requestedterminal ID belongs to. Now, the Dispatcher can use the correct US SCFwithout being concerned with underlying networks.

Embodiment 3 A Framework for Each Network

In this embodiment, one OSA framework incorporates only one underlyingnetwork. For example, the OSA framework in the GSM network has only theresponsibility for the service capabilities in the GSM network, thus itcontrols all the SCFs (CC SCF, US SCF shown in FIG. 11) in the GSMnetwork. The same applies to the PSTN/ISDN network and the IP-basednetwork as shown in FIG. 11.

Each SCF is mapped to the interfaces specific for each network. Forexample, the CC SCF in the GSM network is mapped onto the interfacesissuing Call Control in the GSM network. The same applies to the CC SCFin the PSTN/ISDN network and the IP-Based network. This allowsapplications to make use of service capabilities in all underlyingnetworks, by addressing to each OSA framework separately.

Additional Functionality

A. Selection of Framework Based on the Terminal IDs

The applications must know which framework to address given a terminalID. In this embodiment each framework has an SCF “Terminal IDInformator”. The Terminal ID Informator SCF has an interface allowingapplications to ask whether a terminal belongs to an underlying networksupported by the framework. The ask procedure can be expressed asfollows:

TerminalInfoReq <Terminal ID, belong (True/False)>

The terminal ID together with a true or false is returned from the SCFinterface through the OSA Framework to the asking application. If theterminal does not belong to the framework, the procedure returns a Falseand the application proceeds by asking other frameworks until itreceives a True as answer. The application can then select and use thedesired SCF. The true/false is represented by a Boolean.

Example

An application wants to obtain the user status for a terminal ID, e.g.phone number 12345678. The application sends a query to an OSAFramework, including the <terminal ID>=12345678 and the name of the SCF,<SCFtype>=“User Status”. The OSA Framework forwards the request to theTerminal ID Informator SCF. If the terminal ID exists in that framework,the Informator SCF interface returns a True to the OSA Framework. Theapplication will then select and use the desired SCF. If a false isreturned, the application will send the request to another OSAFramework.

Embodiment 4 Communication and Collaboration Between the Different OSAFrameworks

In this embodiment one OSA framework incorporates only a singleunderlying network, like in the third embodiment. However, in addition,communication and collaboration are enabled between frameworks.Interoperability between frameworks is established and applications mayneed to deal with only one OSA framework, in order to make use ofservice capabilities from many heterogeneous networks (See FIG. 12).

In addition to the SCFs of the “home” framework, the applications canalso use the SCFs belonging to other frameworks on other networks bysimply issuing requests towards their “home” framework. The frameworkwill then communicate with the actual framework to ask for the referenceof the SCF instance. If no such instance was created for theapplication, the “foreign” framework will create one and return thereference to the “home” framework. The “home” will then return thereference to the requesting application. For a Service CapabilityFeature, the application may have references of several SCF instances,which represents different networks such as GSM, PSTN or IP. The serviceproperties of each SCF instance are therefore differentiated. TheTerminal ID Administrator will, when given a terminal ID, return thereference of the SCF to be used. This is illustrated in FIG. 13 showingusage of US SCF in both the GSM network and the IP based network.

Let us suppose that an application selects a User Status SCF in the GSMnetwork and a User Status SCF in the IP-Based network, using theframework in the GSM network. (1. and 2. in FIG. 13.) The US in the GSMnetwork is traded in the usual way as defined by OSA. The framework inthe GSM network should then ask the framework in the IP-based network tocreate a new US SCF instance, using the Service Properties supplied bythe application and return a reference to the US instance to theapplication. (The reference is a pointer to the created SCF instance.The actual embodiment is dependent on the implementation.) Hence, theOSA interface in this embodiment comprises mechanisms to enable aframework to select an SCF in another framework and to be able toreceive a reference to the SCF instance. In FIG. 13 this is 2-1. wherethe OSA Framework in the GSM network selects (trades) the US SCF in theIP-based network, using a method in the OSA Framework Communication APIin the OSA Framework in the IP-based network. Then the framework returnsthe reference to the SCF instance to the application using an ordinarytrading function specified by the OSA standard. In 2-2. in FIG. 13 theOSA Framework IP-based network agrees to the service trading, makes anew instance of a US SCF for the IP-based network and returns areference to the SCF to the OSA framework in the GSM network, which thenreturns the reference to the SCF application.

Additional Functionality

A. Communication Between Frameworks

The OSA frameworks for the different underlying networks know about eachother and collaborate in order to serve the applications. What SCFs thatare offered between the different frameworks are predefined. In additionthe following functions are included in the OSA frameworks:

Authentication Between Frameworks

In order to prevent fraudulent use and attacks it is preferred to have astrong mutual authentication procedure between the frameworks beforeallowing any further operations between them. The authenticationprocedure may be anyone known in the art.

Service Trading Between Frameworks

In this embodiment of the invention every framework is extended with aninterface allowing other frameworks to request information about theSCFs offered by the framework. The interface therefore includes thefollowing SCFrequest method:

SCFrequest(<requestingFrameworkID>, <ListOfSCFoffered>), where

<requestingFrameworkID> is the identity of the requesting framework and

<ListOfSCFoffered> is the list of the offered SCFs, which are offered tothe requesting framework. This list may be different depending on therequesting framework.

When receiving the list of offered SCFs, the requesting OSA frameworksaves the list with offered SCF's in the same way as “local” registeredSCFs. In this way it is able to show it to the requesting applications.It also saves the information about which OSA framework owns what SCFs.Service Usage Between Frameworks

Every framework is extended with an interface allowing other frameworksto use its SCFs. The interface includes the following methods:

getSCFinstance(<serviceID>, <serviceProperties>, <reference>,<frameworkID>, <applicationID>), where

<serviceId> is the ID of the requesting SCF,

<serviceProperties> is the list of properties specified by theapplication belonging to the requesting framework,

<reference> is the reference of SCF instance,

<frameworkID> is the ID of the requesting framework,

<applicationID> is the ID of the requesting application,

With this method an OSA framework can request another framework toreturn the reference of the SCF instance according to the serviceproperties asked by its application. If no such instance exists, theframework will create one. The OSA framework must save the receivedreference with its respective OSA framework. An OSA framework shouldhave a list of SCF instance references and their respective framework.Communication between the OSA frameworks, using the interfaces specifiedabove, is shown in FIG. 14.B. Terminal ID Administrator

Given a terminal ID the application needs to know which SCF instance touse since terminals can belong to different networks and hence behandled by different SCF instances. Again the applications needassistance from the framework. In this embodiment each framework isequipped with a Terminal ID Administrator (TA), which is implemented asan SCF. The TA SCF is similar to the one described in embodiment 1. Inaddition, the TA SCF is supplied with the terminal ID ranges supportedby each OSA framework. (A terminal ID may e.g. be a telephone number oran IP address or a name.) These can be supplied by several ways such asoff-line installation, by enabling interaction between TAs or by havinga common information database.

Example

An application wants to obtain the user status for a terminal ID, e.g.phone number 12345678. The application sends a query to an OSAFramework, including the <terminal ID>=12345678 and the name of the SCF,<SCFtype>=“User Status”. The OSA Framework forwards the request to theTerminal ID Administrator SCF. If the terminal ID exists in thatframework, the application will then select and use the desired SCF. Ifthe requested terminal ID is outside the ranges supported by the OSA,the OSA Framework will request another framework according to theframework list of SCF instance references and their respectiveframework.

Having described preferred embodiments of the invention it will beapparent to those skilled in the art that other embodimentsincorporating the concepts may be used. These and other examples of theinvention illustrated above are intended by way of example only and theactual scope of the invention is to be determined from the followingclaims.

1. A telecommunication system providing extended open service access tomultiple heterogeneous networks, hereafter called underlying networks,the system comprising: one unique common framework for the underlyingnetworks; and a common service capability feature for the underlyingnetworks providing a common network interface, wherein the commonservice capability feature comprising: a mapping means for mapping openservice access interface classes to interfaces of the underlyingnetworks; and a dispatcher means dispatching a request from anapplication to a corresponding network interface class so that thetelecommunication system can simultaneously provide extended openservice access to each underlying network; a terminal ID administratorfor selecting a network service capability feature instance for anapplication based on terminal ID, said service capability featureinstance being selected from a set of multiple service capabilityfeature instances wherein the terminal ID administrator provides aninterface for the dispatcher means, the terminal ID administratorcomprising program means for providing via the interface a reference forthe service capability feature instance in response to receiving via theinterface said terminal ID and an application ID for said application,the dispatcher comprising program means for using the reference todispatch said request to the service capability feature instance.
 2. Atelecommunication system providing extended open service access tomultiple heterogeneous networks, hereafter called underlying networks,the system comprising: one unique common framework for the underlyingnetworks; and a common service capability feature for the underlyingnetworks providing a common network interface, wherein the commonservice capability feature comprising: a mapping means for mapping openservice access interface classes to interfaces of the underlyingnetworks; and a dispatcher means dispatching a request from anapplication to a corresponding network interface class so that thetelecommunication system can simultaneously provide extended openservice access to each underlying network; a terminal ID administratorfor selecting a network service capability feature instance for anapplication based on terminal ID, said service capability featureinstance being selected from a set of multiple service capabilityfeature instances; wherein the terminal ID administrator comprises adatabase/directory containing mapping information between applicationsand terminal IDs.
 3. The telecommunication system according to claim 2,wherein the common service capability features comprising a generalservice property indicating which underlying network a network SCFservice capability feature is interacting with.
 4. The telecommunicationsystem according to claim 3, wherein the service property is a set ofstrings, each string containing a <operator, network> pair.
 5. Thetelecommunication system according to claim 2, wherein the commonnetwork interface comprising service capability interface classesproviding a one to many mapping between applications and interfaces ofthe underlying networks.
 6. The telecommunication system according toclaim 2, comprising a registration interface between the mapping meansand the dispatcher means, said registration interface enablingregistration of the underlying networks with the dispatcher means. 7.The telecommunication system according to claim 2, wherein thedispatcher means comprising selecting means selecting a servicecapability feature instance in response to said request from anapplication.
 8. The telecommunication system according to claim 2,wherein the terminal ID administrator is updated in real time.
 9. Atelecommunication system providing extended open service access tomultiple heterogeneous networks, hereafter called underlying networks,the system comprising: one unique common framework for the underlyingnetworks; and a common service capability feature for the underlyingnetworks providing a common network interface, wherein the commonservice capability feature comprising: a mapping means for mapping openservice access interface classes to interfaces of the underlyingnetworks; and a dispatcher means dispatching a request from anapplication to a corresponding network interface class so that thetelecommunication system can simultaneously provide extended openservice access to each underlying network; a terminal ID administratorfor selecting a network service capability feature instance for anapplication based on terminal ID, said service capability featureinstance being selected from a set of multiple service capabilityfeature wherein the terminal ID administrator comprises adatabase/directory containing mapping information between applicationsand the service capability feature instances, between the servicecapability feature instances and the underlying networks, and betweenthe underlying networks and the terminal IDs.